Apparatus and method for acquiring, managing, sharing, monitoring, analyzing and publishing web-based time series data

ABSTRACT

A computer-implemented method of providing time series data includes maintaining by a web server user account data for each of a plurality of user accounts. Each account is associated with a user. The method includes, for each user having a user account, serving by the web server a set of web pages configured to support uploading of time series data to the web server, including updates of such data from time to time; storing by the web server the uploaded time series data; and serving by the web server a set of web pages configured to present such data to such user. Related methods include a method for web-publishing the data, and loading the data into applications running locally. There is also provided a digital storage medium encoded with instructions that when loaded into a computer establish processes that implement any of these methods.

RELATED APPLICATIONS

The present application is a divisional of U.S. application Ser. No. 13/801,827, filed Mar. 13, 2013, now U.S. Pat. No. 9,984,125, which claims the benefit of U.S. provisional application Ser. No. 61/653,818, filed May 31, 2012, having the same title as the present application. Application Ser. No. 13/801,827 is hereby incorporated herein by reference in its entirety.

TECHNICAL FIELD

The present invention relates to web pages, and more particularly to apparatus and methods for acquiring and managing time series data extracted from web pages, as well as the transformation, publication, sharing and use by and among individuals, of this data.

BACKGROUND ART

It is well known in the prior art to serve web pages to web browsers running on client computers. Many web pages include time series data. Typically the time series data are in a wide range of formats. A person desiring to acquire, monitor, manage, and analyze time series data found on web pages must therefore be prepared to handle this range of formats.

SUMMARY OF THE EMBODIMENTS

In a first embodiment of the invention there is provided a computer-implemented method of acquiring and managing web-based time series data.

The method of this embodiment uses computer processes including:

receiving over a network, from a requesting process running on one of a client computer and a server, at least a URL for web-based time series data; resolving the web-based time series data by using the URL to access the web-based time series data, extracting the web-based time series data, and converting the extracted web-based time series data into a normative format to produce normalized time series data; and transmitting over the network the normalized time series data to the requesting process.

In a related embodiment receiving includes receiving contextual data with the URL and using includes using the URL with the contextual data. Alternatively or in addition, converting the extracted web-based time series data includes (i) using the URL to select a previously derived and stored normalization process appropriate for the web-based time series data; and (ii) running the stored normalization process. Optionally, converting the extracted web-based time series data includes (i) using the URL and the contextual data to select a previously derived and stored normalization process appropriate for the web based time series data; and (ii) running the stored normalization process.

In another related embodiment, the web-based time series data is displayed on a web page running in a browser of a client computer. In this embodiment the method further includes serving, to a client process running in the browser, from dot data storage, algorithmic data pertinent to time series data available from the URL, such algorithmic data causing the client process to populate the web page displayed on the browser with at least one active marker, such marker indicating the presence of time series data available via the web page, and located on the displayed web page adjacent to the time series data, so that, when the active marker is graphically invoked on the client computer, the algorithmic data in cooperation with the client process, will trigger transmission of the URL to a server and invoke the processes of receiving, resolving, and transmitting. In another embodiment, the invention provides a computer-implemented method of handling time-series data. The method of this embodiment includes: receiving over a network from a client computer browser process a user-initiated request to monitor time series data found through a specified URL; causing use of the URL to access the time series data, extraction of the time series data, and conversion of the extracted web-based time series data into a normative format to produce normalized time series data; storing the normalized time series data; causing the stored normalized time series data to be updated repetitively over time; and granting access by the client computer to the stored normalized data.

In a related embodiment, the client computer is operated by an account holder, and the method further includes serving to the client computer a listing of names of time series data collections stored for the benefit of the account holder, wherein the listing is configured so that, when displayed on the client computer, the name of the collection associated with the specified URL is displayed with an icon serving as a trademark for the collection associated with the specified URL and wherein the icon also includes a hyperlink to the specified URL.

In another related embodiment, the client computer is operated by an account holder, and the method further includes granting access to the stored normalized data by another client computer operated by a person having authorization from the account holder. In another embodiment, the invention provides a computer-implemented method of handling time-series data, and the method includes:

receiving over a network from a client computer browser process a user-initiated request to store time series data from a user-specified data source, wherein the client computer is operated by an account holder; accessing the time series data from the user-specified data source; determining whether the time series data is normalized, and, if so, storing the time series data; rendering the time series data in at least one user-specified format and generating a URL to identify the rendered data; and granting access to the URL in accordance with permissions granted by the account holder.

In another related embodiment, the requesting process is initiated from a client computer of a user having a user account and the user account has been identified as a source of the requesting process, and resolving the web-based time series data includes allocating processing of incoming data including at least identity of the URL to a selected one of a set of servers configured as peers; transmitting a query message, from the selected one of the set of peers, including the identity of the user account, to a dedicated registry server that maintains a registry associating each user account with a corresponding one of the peer servers; receiving, by the selected one of the peers, a response from the dedicated registry server identifying a given one of the peer servers as corresponding to the identified user account; if the selected peer server is not the given one of the peer servers, then transmitting by the selected peer server the incoming data to the given one of the peer servers for processing; processing by the given one of the peer servers of the incoming data to accomplish resolving the web-based time series data; transmitting by the given one of the peer servers to the selected peer server a job completion message; and wherein the selected peer server accomplishes transmitting over the network the normalized time series data to the requesting process; and if the selected peer server is the given one of the peer servers, then processing by the selected peer server of the incoming data to accomplish resolving the web-based time series data, and wherein the selected peer server accomplishes transmitting over the network the normalized time series data to the requesting process.

In another embodiment, the invention provides a computer-implemented method of making updated time series data available to a client computer of a given user having a user account, the time series data having been graphically selected by the given user. The method of this embodiment includes serving by a time series server the time series data in a web page over a wide area network in such a manner that, when a user of a client computer displaying the time series web page graphically selects the time series data to be made available, there is provided to the server by the browser a unique identifier of an underlying location, of the time series, wherein the time series data is stored on the server; receiving at the server the unique identifier as a result of the graphical selection of the time series data by the given user; and modifying data associated with the given user's account so as to associate the unique identifier with the given user's account, so that when the given user, via a client computer, seeks to access the time series data having the unique identifier, then the time series data is retrieved from the underlying location, and so that whenever the time series data is updated at the underlying location the time series data accessible by the given user is also updated.

In yet another embodiment, the invention provides a computer-implemented method of making an updated display of time series data available to a client computer of a given user having a user account, the display having been graphically selected by the given user. The method of this embodiment includes serving by a time series server the display in a web page over a wide area network in such a manner that, when a user of a client computer rendering the display of time series data graphically selects the display of time series data to be made available, there is provided to the server by the browser a unique identifier of an underlying location of the display of time series, wherein the display of time series data is stored on the server; receiving at the server the unique identifier as a result of the graphical selection of the display by the given user; and modifying data associated with the given user's account so as to associate the unique identifier with the given user's account, so that when the given user, via a client computer, seeks to access the display of time series data having the unique identifier, then the display of time series data is retrieved from the underlying location, and so that whenever the display is updated at the underlying location the display accessible by the given user is also updated.

In yet another embodiment, the invention provides a computer-implemented method of providing time series data. The method of this embodiment includes maintaining by a web server user account data for each of a plurality of user accounts, each account associated with a user; for each user having a user account:

serving by the web server a set of web pages configured to support uploading of time series data to the web server, including updates of such data from time to time;

-   -   storing by the web server the uploaded time series data; and     -   serving by the web server a set of web pages configured to         present such data to such user.

In a related embodiment, the method further includes, for each user having a user account serving, by the web server, web pages configured to support building by such user of a web-embeddable display of such user's time series data and for such user to obtain a link to the display of such user's time series data thus built, so that such link, when embedded in a script for a user web page served by or on behalf of such user, will cause the display of such user's time series data to appear in a browser that is displaying the user web page, so that such user can cause the display of such user's time series data to be published on the World Wide Web.

In a further related embodiment, the web pages configured to support building a web-embeddable display of such user's time series data are additionally configured to enable such user to include, in such display of such user's time series data, time series data from a source other than such user. Optionally, the source is another user account maintained by the web server. Alternatively, the source is time series data from a third party that has been imported by such user into such user's user account.

A further related embodiment further includes serving by the web server, to a client computer of a user having a user account, a web page, the web page including time series data, wherein the web page is configured so that when it is displayed in a browser of the client computer, there is provided a graphical device associated with the web page to facilitate export of the time series data displayed in the page to an application running on the client computer. Optionally, the application is a spreadsheet. Alternatively, the application is a charting tool. Optionally, the graphical device causes display of an identifier associated with the display of such user's time series data, and the method further includes serving updated time series data to the spreadsheet application via a plug-in for the spreadsheet application.

In another embodiment, there is provided a non-volatile digital storage medium encoded with instructions that when loaded into a computer establish processes that implement any of the method embodiments previously recited. A separate storage medium embodiment corresponds to each one of the method embodiments previously recited.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing features of embodiments will be more readily understood by reference to the following detailed description, taken with reference to the accompanying drawings, in which:

FIG. 1 is a block diagram showing system architecture of a an embodiment of the present invention;

FIG. 2 is a block diagram showing logical flow of the TS Resolver server in accordance with an embodiment of the present invention;

FIG. 3 is a block diagram showing logical flow of a user's client computer in communicating with the TS Resolver server in accordance with the embodiment FIG. 2;

FIG. 4 is representation of a display of a web page that illustrates placement of the DataZither Dot on the home page of the Bureau of Labor Statistics at BLS.gov in accordance with an embodiment of the present invention;

FIG. 5 is representation of a display of a web page that illustrates placement of the DataZither Dot on the Interactive Pages of the Bureau of Economic Analysis, which has a home page at BEA.gov in accordance with an embodiment of the present invention;

FIG. 6 is representation of a display of a web page that illustrates DataZither Dots on the Financial Statement Pages, for GE Corporation, of WSJ.com, in accordance with an embodiment of the present invention;

FIG. 7 is representation of a display of a web page that illustrates placement of a DataZither Dot in a web page of the Bank of England in accordance with an embodiment of the present invention;

FIG. 8 is representation of a display of a web page that illustrates the effect resulting when a user causes the mouse-driven icon to hover over a DZDot in accordance with an embodiment of the present invention;

FIG. 9 is a block diagram showing processes carried out by the DZ Dot browser add-on 141 in placing a DataZither Dot, in accordance with an embodiment of the present invention, at the time of loading of a web page having numeric data;

FIG. 10 is a block diagram showing processes carried out, in accordance with an embodiment of the present invention, by an application (such as DataZephyr 143 running directly on client computer 14 or the DataZoa server 17 in conjunction with the DataZoa web page running in browser 142 of client computer 14) in relation to the TS Resolver Server 16 in accessing normalized data from a third party web site;

FIG. 11 is representation of a display of a web page that illustrates a user interface for an embodiment of the present invention implementing publishing features of DataZoa;

FIG. 12 is representation of a display of a web page that illustrates how publisher icons and clickable links appear in a data listing view of an end user's DataZoa account in accordance with an embodiment of the present invention;

FIG. 13 is representation of a display of a web page that illustrates a user interface, in accordance with an embodiment of the present invention, for causing the sharing of data among DataZoa account users;

FIG. 14 is representation of a display of a web page that illustrates an aspect of the user interface of an embodiment of the present invention by which time series data appearing in a DataZoa table of the sort described in connection with FIGS. 18 and 19 may be imported into the DataZephyr charting and analysis application 143;

FIG. 15 is a representation of a display of a web page showing an aspect of the user interface of an embodiment of the present invention by which time series data appearing in a DataZoa table of the sort described in connection with FIGS. 18 and 19 may be imported into the user's DataZoa account;

FIG. 16 is a representation of a display in which is presented an example of a graph of an epochal time series in accordance with an embodiment of the present invention;

FIG. 17 provides detail of FIG. 12, showing, among other things, in each row, the web URL of the corresponding data in the DataZoa account as well as the favicon for such data;

FIG. 18 is representation of a display of a web page that illustrates an exemplary DataZoa-served table, in accordance with an embodiment of the present invention, which (among other things) can be inserted into any web site by using the link served up by the DataZoa table builder, which in turn is depicted in FIG. 19;

FIG. 19 is a representations of a display of a web page in which is presented the table-building tool of DataZoa that was used to render the finished, web-delivered table in FIG. 18 in accordance with an embodiment of the present invention;

FIGS. 20 and 21 are representations of displays of web pages in which appear DataZoa-served tables in accordance with an embodiment of the present invention providing the user with a series of options for using the time series data in the table, including the “follow” option by which the user may subscribe to time series data in the table;

FIG. 22 similarly illustrates a web pages in which appears a DataZoa-served bar chart in accordance with the same embodiment as FIGS. 20 and 21, wherein the user with a series of options for using the time series data in the bar chart, including the “follow” option;

FIG. 23 is a representation of a display of a web page of a DataZoa user account using the “Latest Arrivals” screen (which is a default “dZBoard”) of the dZBoards feature associated with a DataZoa user account in accordance with an embodiment of the present invention and showing the appearance in the account of the tables of FIGS. 22 and 20 after election of the “follow” option for such tables;

FIG. 24 is a representation of a display of a web page of a DataZoa user account showing another screen (which is a user-customizable “dZBoard”), of the dZBoards feature associated with a DataZoa user account in accordance with an embodiment of the present invention, wherein one can compose a web page including text and one or more tables or charts or both that are served by DataZoa, and cause the web page to be shared privately or publically for viewing on any web-enabled device;

FIG. 25 is a representation of a display of a web page in which appears a DataZoa-served display in accordance with an embodiment of the present invention, wherein a user is provided with options, labeled with the Grey dZDot, for use of the display or its underlying data, including the “follow” option (here indicated as a “send” option) by which the user may subscribe to time series data in the row or in the entire display and have the subscribed data appear in the user's DataZoa account;

FIG. 26 is a representation of a display of a web page in which appears a DataZoa-served table in accordance with an embodiment of the present invention, wherein an option is presented to have data in the tabled mirrored in a spreadsheet and repetitively updated in the spreadsheet;

FIG. 27 is a representation of display of an Excel spreadsheet in which there has been installed a DataZoa add-in, which has been invoked so as to trigger a pop-up window by which one can enter a URL to identify a table (such as the table of FIG. 26) that is to be mirrored in the spreadsheet and to specify the update frequency by which the data in the spreadsheet will be updated, all in accordance with an embodiment of the present invention;

FIG. 28 is a representation of display of an Excel spreadsheet in which there have been mirrored a number of DataZoa-served tables, using the DataZoa add-in of FIG. 27, in accordance with an embodiment of the present invention;

FIG. 29 is a representation of a display of a web page of a DataZoa user account using the DZ Slates feature by which the user can create and e-mail a web page, repetitively if desired, to a data contributor of the user, for use by the contributor in causing a direct upload, to the user's designated URL, of the contributor's data in accordance with an embodiment of the present invention;

FIG. 30 is a representation of a display of a web page that results when the data contributor of FIG. 29, having received the e-mailed web page, activates the “slate” by which the data contributor can enter data, requested by the user, directly to the user's designated URL in accordance with an embodiment of the invention providing the DZ Slates feature;

FIG. 31 is a representation of a display of a web page by which the user can configure and edit the context in which the data contributor can enter data, including target URL for data upload, contributor e-mail address, optionally required password, and greeting to the contributor, in accordance with an embodiment of the invention providing the DZ Slates feature;

FIG. 32 is a representation of a display of a web page proving to the user guidance on configuring and using DZ Slates for gathering data;

FIG. 33 is a block diagram of system architecture of an embodiment of the present invention for implementing the DataZoa server 17 of FIG. 1 as a series of peer-to-peer servers for handling loads larger than could be handled by a single server;

FIG. 34 is a block diagram of logical flow for the system architecture of FIG. 33;

FIG. 35 is a block diagram of logical flow for processes by with the DataZoa server 17 of FIG. 1 causes time series data stored by it to be updated;

FIG. 36 is a block diagram of logical flow and user interaction by which a data in a DataZoa-served table can be mirrored in a spreadsheet in accordance with an embodiment of the present invention;

FIG. 37 is a block diagram of logical flow in connection with an embodiment of the present invention wherein the “follow” functionality has been invoked with respect to a time series; and

FIG. 38 is a block diagram of logical flow in connection with an embodiment of the present invention wherein the “follow” functionality has been invoked with respect to a dZEmbeddable display of time series data.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS Definitions

As used in this description and the accompanying claims, the following terms shall have the meanings indicated, unless the context otherwise requires:

“Web-based data” is data that is accessible from one or more web sites by a client computer running a web browser.

A “web page identifier” is data identifying a web page, such as a uniform resource locator (URL) or IP address.

A “normative format” is a uniform format, employed for storage of time series data, configured so that identical sets of data are displayed identically when rendered by the same processes, even though such sets of data may have been obtained from host web sites or other sources in differing formats.

To “resolve” a web page means accessing the web page over a network using a web page identifier for the web page, extracting web-based time series data from the web page, and converting the extracted web-based time series data into a normative format to produce normalized web-based time series data.

A “resolver server” is a server configured to resolve a web page for which it has been provided a web page identifier.

A computer “process” is the performance of a described function in a computer using computer hardware (such as a processor, field-programmable gate array or other electronic combinatorial logic, or similar device), which may be operating under control of software or firmware or a combination of any of these or operating outside control of any of the foregoing. All or part of the described function may be performed by active or passive electronic components, such as transistors or resistors. In using the term “computer process” we do not necessarily require a schedulable entity, or operation of a computer program or a part thereof, although, in some embodiments, a computer process may be implemented by such a schedulable entity, or operation of a computer program or a part thereof. Furthermore, unless the context otherwise requires, a “process” may be implemented using more than one processor or more than one (single- or multi-processor) computer.

A “time series” is a time-ordered series of observations pertinent to a phenomenon, wherein each observation has a value that may be a numeric value, a state value or a combined numeric and state value.

An “epochal time series” is a time-ordered series of states of a phenomenon at various points of time, which can, but need not, be regularly occurring. As an example, the phenomenon may be chairmanship of the Federal Reserve and the state may be the identity of the Chairman of the Federal Reserve. This identity is a state variable that changes from time to time, sometimes at irregular intervals, and may even be indeterminate during a period when the position of Chairman is temporarily empty or not knowable. A state may be represented, among other ways, by a name or an image (such as a picture of the Chairman of the Federal Reserve). Each state value in an epochal time series may also have descriptive or qualifying information associated with it, such as a flag that the current Chairman of the Federal Reserve is an interim or temporary position holder, or any other descriptive information having a bearing on the meaning or interpretation of that state value. An example of an epochal time series is shown in FIG. 16, wherein the state value is the identity of the President of the United States, which is depicted in a DataZoa-served chart, along with a numeric time series, in this case, the Consumer Price Index.

A “numeric time series” is a time-ordered series of numbers measuring a phenomenon at various points of time, which can, but need not, be regularly occurring. Each such number in a numeric time series may also have descriptive or qualifying information associated with it, such as a flag that is “preliminary” as is common with economic information releases, or any other descriptive information having a bearing on the meaning or interpretation of that number.

A “calculated series” is a time series that is a mathematical transformation of one or more other time series. When the calculated series is itself a transformation of at least one calculated series, so as to result in a set of nested calculations, then there must be an innermost time series that is not a calculated series.

A “user account” with a DataZoa or other time series server is an account, of a registered user of information provided by a DataZoa server or a similar server, that associates with the registered user, among other things, data that the registered user has identified for preservation, potentially including time series data, display specifications, and calculation specifications for calculated series.

A “shard” of a DataZoa server or other time series server is a group of one or more user accounts physically served by a single peer server in a set of peer-to-peer servers that collectively serve all user accounts.

A “time series server” is a web server configured to store and serve time series data for a plurality of users, wherein each user has a separate user account by which such user can store and access time series data using a web pages.

A growing number of web sites worldwide are being increasingly relied upon by users to provide numeric or state information about some subject for which the numbers or states presented change over time, often carrying a trail of historical numbers and states respectively, as well as associated descriptive information for some or all of such numbers or states. The ranges and kinds of such data are vast. As examples, such data may be the Unemployment Rate, a high school's graduation rate, the rate of hospital acquired infections for a specific hospital, a baseball player's batting average or game log, the identity of an athlete holding a world record at any particular point in time, the most popular pop-song, the name of a county's president, or a security price. Embodiments of the present invention facilitate the acquisition, maintenance, date/time stamping, dissemination and use of such data. Additionally, a growing number of owners or publishers of numeric and state data are using such data for marketing purposes, in order achieve new or maintain existing connections and relationships with prospects and customers respectively, or merely to give “free samples” of data which they sell, to help inform prospective customers on their products, and then sell and deliver the full data collections behind the samples. Embodiments of the present invention facilitate the efforts of the owners and publishers of numeric data to utilize it for such marketing purposes, and to move this data into broader access and use in ways which extend their brand, name and data products further into the marketplace, while making it easy for those discovering and using this data to find their way back to the owner or publisher of the data, including in particular, the owner or publisher's web site. Further, various embodiments of the invention address important unmet, and insufficiently met, needs of users of numeric data which may have deep history and/or flows over time.

More specifically, embodiments of the present invention enable such users to have their numeric data (which, by its nature, continues to grow as a numeric time series) collected and kept current in a single place and in a consistent format, so that this data may be used by any of a variety of applications running locally on a computer or smartphone or on a server-based system, and at any time in any of a variety of settings. Additionally, embodiments of the present invention enable owners and publishers of data to put out their data to users or customers of that data in a consistent format and through a consistent set of interfaces, which by their nature increase the utility of that data. For example, embodiments herein enable a publisher to offer a table of many time series on a web site, from which a site visitor or user might select one or more series of interest, which would then be made instantly available in the user's DataZoa account, where the user could combine it and use with other data of interest to the user. Embodiments of the present invention also enable users who hold accounts to act as publishers of data and to share the data publicly or privately with others.

The ability of embodiments herein to accept, provide, and handle data in a dynamic and growing time series contrasts with prevalent tools, such spreadsheets, that restrict the user to data spanning a specific time frame for evaluation, and thereby hamper user access to, and use of, deeper historical data, as well as dynamic new data. The comparison of embodiments herein, which elegantly handle dynamic time series data, with spreadsheets, which are restricted to data in a specific time interval, is similar to the comparison of digital video, which elegantly handles dynamic changes in a scene, with a still photograph, which cannot.

The easy capture of, and access to, virtually any depth of history of a numeric data stream, as well as the easy utilization of new values as they appear or are produced by various sources and systems, provide considerable convenience and time-savings to users in comparison to current common approaches. The ability to have a format-consistent, and automatically updating, or easily user-updated reservoir of numeric data of types which flow and grow over time, may be a unique enabler of many types of uses by many types of users. Finally, the ability in various embodiments hereof to facilitate sharing by users of these data streams and historic data, both privately to individuals of their choosing, and publicly, on a data-item-by-data-item basis, further enables and increases the productivity of still other uses and users respectively of this type of data.

FIG. 1 is a block diagram showing system architecture of an embodiment of the present invention. A series of servers, each independently running a distinct set of processes, identified as DZ Dot Server 15, TS Resolver Server 16, and DataZoa Server 17, are coupled to the internet 11. For purposes of scaling, there may be multiple instances of each of these servers, but for simplicity in illustration we show a single server of each type. These servers communicate independently over the internet 11 with processes running on client computers. There may be a very large number of client computers, but we show a single client computer 14 for convenience of illustration. In FIG. 1, the client computer 14 is running three processes, namely, a browser process 142 with respect to which the user has directed the browser to access a web page from the DataZoa Server 17, a DZ Dot browser add-on process 141, and a DataZephyr dedicated application process 143. In practice, a given client computer need not run all of the processes 141, 142, and 143 simultaneously (and might run only one or two of the processes at all), because each such process can operate independently of the other processes, although, as we shall see, the processes perform complementary functions. We sometimes refer to the system of FIG. 1 as the “DZ system” or simply “the system”.

As an illustration of the operation of the processes 141, 142, and 143 in relation to the servers 15, 16, and 17, let us suppose that a user has caused the browser of client computer 14 to access, over the internet 11, the web site of a third party server 12. The server 12 serves to the browser of the client computer 14 a web page displaying numeric time series data from storage 121, which is accessed by the server 12. In this example, this web page served by server 12 has been previously analyzed, and its URL has been stored on DZ Dot Server 15, which also stores, in association with the URL, a location on the displayed web page for placement of what we call a “Data Zither Dot” or “DZ Dot”, as discussed in further detail in relation to FIGS. 4-7. In this description and the accompanying claims, we sometimes refer to the DZDot as an “active marker”. As discussed in further detail in connection with FIG. 9, the DZ Dot browser add-on process 141 running on the client computer 14 communicates over the internet with the DZ Dot Server 15 to obtain data, from Dot Data storage 151, that defines placement of the DZ Dot on the displayed web page served from third party server 12. (In this example, the DZ Dot does not reside on the web page served by third party server 12; instead the DZ Dot Server 15 and DZ Dot browser add-on process 141 cause the DZ Dot to appear on the display of the web page in the browser process of client computer 14.)

A user of the client computer 14 of FIG. 1 can use a mouse to graphically select the DZ Dot that has been caused to appear on the display of the web page and will be presented with a menu of choices generated by the DZ Dot browser add-on process 141. The menu gives the user a list of destinations for the numeric data, on the displayed web page, that is identified by the selected DZ Dot. From the list the user can select a destination for the data. One such destination that may be selected by the user, for example, is the dedicated DataZephyr application 143 that is running on the client computer 14. The DataZephyr application 143 provides charting and analysis of data, and is particularly suited to charting and analyzing time series data, among other things.

Also in this example, the structure of the time series data served by server 12 of FIG. 1 has been previously analyzed and stored heuristically on TS Resolver Server 16 as a script in script storage 161. The script includes data that characterize the one or more URL locations where the numeric time series data can be accessed from server 12, as well the organization of the time series data. Let us assume that the user has invoked the DZ Dot and selected the menu choice to have the time series data served by server 12 of FIG. 1 sent to the DataZephyr application 143 running on the client computer 14. Such a user selection causes the DZ Dot browser add-on process 141 to send the URL and other information identifying this data to the destination application DataZephyr 143. The destination application in turn sends the URL and other identifying information over the internet to the TS Resolver Server 16. In turn the TS Resolver Server 16 accesses a script for the data identified by the DZ Dot, normalizes the data, and sends the data over the internet to the client computer 14, where the data is received by the destination DataZephyr application 143.

Another possible destination for the data that may be selected by the user on invoking the DZ Dot is the DataZoa server 17. Each user of the DataZoa server 17 has an account for which data is stored in the User Data storage 172 accessible by the server 17. Let us now assume that our user of client computer 14 has an account for the DataZoa server 17, that the user has now selected the DataZoa server 17 as the destination for the time series data displayed in the browser of client computer 14. In this case, the DZ Dot browser add-on process 141 would send the URL and other information identifying this data to the DataZoa application 142. The DataZoa application then sends the URL and other identifying information over the internet to the TS Resolver Server 16. In turn, the TS Resolver Server 16 accesses the script for the data identified by the DZ Dot, normalizes the data, and sends the data over the internet to the DataZoa server 17, where it is stored in Normalized Data storage 171 in association with the user's account. The DataZoa server 17, depending on configuration of the user account and parameters associated with the server 17, will update on a period or other basis the data stored in Normalized Data storage 171, so that the user may access periodically updated data each time the user seeks data from storage 171 and does not need to go through a manual update cycle. A user with a DataZoa account can share data easily by selectively giving permission to another to access, possibly under specified conditions, some or all data of the user in the account. Another, and a related, facility of DataZoa lies in the ability of a user with a DataZoa account to publish selected data that is in the account. Further aspects of this system are described below.

FIG. 2 is a block diagram showing logical flow of the TS Resolver server in accordance with an embodiment of the present invention. In process 21, the TS Resolver receives a data request from the requesting application 141 or 143. The data request is in the form of an information package including a URL that identifies the web page containing data of interest to the user, and, when appropriate, locational data that identifies the location in the web page, or elsewhere, of the data of interest to the user, as well as metadata that identifies the target application selected by the user and may provide additional data to the server, such as user credentials and date/time stamps. The application, in turn, obtains the content of the data package from DZ Dot browser add-on process 141. In process 22, the TS Resolver determines whether it has received enough data from the client computer 14 to extract useful data from the identified web page at the identified location. If in process 22, the TS Resolver determines that it does not have enough data, then in process 25, it sends information in response to the requesting process 142 or 143 application, which in turn responds in a manner appropriate to the condition. In process 23, if the TS Resolver determines that it has enough data to do these things, then it accesses the identified web page, extracts the target data based on the locational data, normalizes the extracted data, and stores the extracted data in an array. In various embodiments, the array is implemented as a text-based TSV table, which optionally may be encrypted. Finally, in process 24, the TS Resolver transmits the extracted data to the target application that was selected by the user.

Examples of such normalized data appear in the documents attached hereto and incorporated herein by reference as Appendix B and Appendix C. In Appendix B, we show time series data taken from the St. Louis FRED Unemployment Rate, It can be seen that the normalized data include a header with entries for Title, Series ID, Source, Release, Seasonal Adjustment, Frequency, Units, Date Range, Last Updated, and Notes. Similarly, in Appendix C, we show time series data taken from an Estonia web site that results from use of a query form provided on the site. The normalized data include a generally similar header and also include URL data that enable replicating the query for updating the time series, and a parameter specifying the frequency of updates.

FIG. 3 is a block diagram showing logical flow of a user's client computer 14 when the user seeks to import time series data, from a web page open in the browser of client computer 14, into the user's client side application running locally on the client computer 14 for charting and manipulating such extracted data, which we call the DataZephyr application. In process 31, the browser of client computer 14 receives and loads a user-selected web page and the DZ Dot browser add-on process 141 receives a user's graphical selection of data of interest. In process 32, the DZ Dot browser add-on process 141 receives the user's selection of a target application to receive the data of interest. In process 33, responsive to an action by the user triggering the importing of time series data to the application, the DZ Dot browser add-on process 141 establishes a package of information including a URL for the displayed web page, and if appropriate, locational data to identify the data of interest on the displayed web page, and metadata that, among other things, identifies the target application to receive the identified data. In process 34, the information is transmitted by the browser process to the TS Resolver. Finally, in process 35, the identified data, after having been normalized, is received in the target application from the TS Resolver.

Similar processes are invoked for importing web-based time series data to destinations other than the DataZephyr application, for example, when the target application is the user's web-based account for hosting such data, which we call a DataZoa account Additionally, in a further embodiment of the present invention, the DZ Dot browser add-on process 141 operates to cause transfer of the normalized time series data from the TS Resolver Server 16 to any other software application or system, be it on a client computer or server, which has been enabled to receive such data. For example, a client-side connector enables the user to drag and drop the selected data of interest into a spreadsheet. In that context, the data may optionally be automatically registered in a user's parallel DataZoa account, so updating of the data is managed by the DataZoa account. Alternatively, the client-side connector is configured to seek updates from the original data source, via the TS Resolver Server 16. These embodiments thus enable other software programs or systems of the user to receive the data retrieval, storage, and updating benefits of the system described herein

Once the data is extracted, the URL, metadata, and locational information for subsequent extractions is also sent to the user's targeted application. In various embodiments herein, a unique “fingerprint” and serial number or “key” for the data is created at this time, which is valuable in maintaining of the integrity of the system's automatic and other data update processes. More particularly, the name of the data source, various dimensional attributes of the data (see DZDimensions below), and the numeric values themselves, are used alone or in combination to create the fingerprint, and the key corresponding to that fingerprint is logged along with it in a database. The purpose of doing this is to accommodate situations where there is a change in one or more attributes of the data source such as its main web URL or naming conventions relating to some or all of the utilized data. In various embodiments, by maintaining a system of fingerprints and key identifiers, the process of updating or rewriting a data source connector and deploying into a live data updating context is helped considerably. The individual rewriting or updating a connector in that situation can easily map new names for data dimensions and Attribute:Value pairs onto the existing data dimension and Attribute:Value pairs, and the match of data from the source using new naming conventions can be confirmed to some level of statistical certainty through the comparison of data values, and in particular trailing data values, to those previously attributed to that same data under its prior naming conventions and other dimensional characterizations.

An important aspect to various embodiments of the present invention in general, and not limited to the above case, is the technique of checking that a collection of data being updated, such as a specific time series of values, is the proper collection. Such checking is accomplished by numerical comparison of prior date and/or time-stamped values contained within the DZ system to those values observed in a data update cycle for what appears to be the same data collection. A failure to match generates an exception report which can be evaluated (by a human supervisor when necessary) in a timely fashion, so as to increase the integrity of the data update process.

The user's targeted application can be configured to request updates obtained from the original data source via the TS Resolver at any user-selected range of frequencies, and based on any type of user-selectable trigger, such as a calendar, a set polling frequency, of a notification that data has changed or may have changed. The user's targeted application will then update its copy of the data on receipt, and in further embodiments, make its own record of the date and time associated with the acquisition of any new values; such embodiments may further place date or time stamps on state data which is found without associated date/time stamps in situ thereby utilizing the date and time when each new data value was found as one option for the date/time attribute needed to make the data values found into usable time series. In further related embodiments, the DZ system is configured to identify or poll for updates that are pertinent to data in the user's target destination (such as DataZephyr dedicated application 143 or DataZoa account 17 maintained on DataZoa server) and push these updates to the user's target destination. In a simpler embodiment the DZ system is configured to regularly (e.g., daily) revisit all data being monitored by a DataZoa account holder, for example, and make a comparison of the user's data to data from the sources' to determine if there are any changes or additions to such data. This checking for updates may be implemented by the TS Resolver Server 16 itself or may be driven by requests from a target destination like DataZephyr 143 or the DataZoa account. In either event of a detected change, the TS Resolver server, or independently of any change-checking (e.g., in the case of a request by the target destination) new data is fetched and transmitted to the target destination. Importantly, in the general case of DataZoa use, and as enabled by the above-mentioned practice of DataZoa giving each data collection a unique key when it is initially requested by the user, when DataZoa is storing the same data collection for multiple users, when it is determined that data has changed in one of the collections (which may in some embodiments be determined using attribute data as opposed to the underlying numerical data, or in some further embodiments by performing checksum operations on all or data-specific portions of the web pages, files or other data-containing medium used) the TS Resolver makes only a single fetch of new data and shares the results of that data fetch with all DataZoa users monitoring that specific collection. In further embodiments of DataZoa, the sharing of the results of data fetch among all DataZoa users can be achieved by giving all users of a given such collection or data series a file pointer to one or more master copies of that collection or series, with the benefit to all users being that their copy of that data is immediately and simultaneously updated upon the completion of the fetch/es of the master copy/ies. In another further embodiment, when any user makes from a DZ compliant application (such as DataZoa or DataZephyr), a request for a data collection or series that has been not previously requested by that user, but is already being monitored by other users of DataZoa, the user is offered the option to get a near instantaneous data fetch result by being given from a master copy of the data in question, a file pointer and associated data header information in the user's DataZoa account or other DZ compliant application. This approach avoids the need and delay associated with composing an original normalized data array corresponding to the user's request. The determination of the identity between the requested data and existing data in DataZoa is achieved by comparing the unique key for that for the requested data collection to a pre-existing master index of all data collection keys. Yet another beneficial embodiment involves allowing any data request by any user at any time, including automated requests, upon discovering that data corresponding to a unique key has changed, to provide, to all users, updates by one of the above-described methods.

When the data comes back from the TS Resolver, it may have added to it a set of DZDimensions™, either by the TS Resolver or a process running upon the return of the data. These DZDimensions are Attribute:Value pairs such as Country:USA or Gender:Male. The DZDimensions may be inferred by the connector from the observed data or may be set based on programmer knowledge of the data source in question. The DZDimensions are important in that they may be subsequently utilized as a basis for searching, selecting, aggregating or statistically distributing a collection of data. Such searching may be conducted within Normalized Data storage 171 by the DataZoa server 17 in or any other search system, including a public search engine if the relevant data is presented to such engine.

In various embodiments, users and publishers have the ability to specify such dimensional attributes in their own data which they upload to a DataZoa account. Further embodiments of the present invention are configured so that users and publishers can add the their own dimensional and other attributes and identifying tags to data they have accessed from another source, such as through the TS Resolver system. Alternatively or in addition, users and publishers can override dimensional and other attributes provided by the DZ system. This functionality enables the user to map such data into the user's own contexts and needs more easily and directly. For example, if a user has defined the user's own fantasy baseball team, assigning team roles to various players drawn from various sports teams, in spite of what DZDimensions as to player roles and teams might be inferred automatically by the TS Resolver Server 16 from the data source used, the user can make independent decisions as to such attribute:value pairs as Position:Pitcher, Team:MyBestTeam.]

We now turn to the user interface for identifying data of interest on a web site selected by the user. We have built connectors for many web sites having numeric data of interest to users, to facilitate access by users to such data, including for purposes of monitoring dynamic numeric data, which may typically be numeric time series (either uniform-interval series, e.g., weekly or monthly, or non-uniform-interval series, e.g., resulting from transaction flow). Embodiments herein enable users to access and monitor such data from their own DataZoa™ account or via a DZ-enabled application such as DataZephyr™, which is a desktop software application for displaying and manipulating such data.

In various embodiments of the present invention, the data found on a public web site is flagged by a green dot, which we variously call a DZDot™ or a “DataZither™” dot (which can be graphically selected by the user to cause selection of the corresponding data). The flagging by the DZDot is achieved in the user's browser view of a visited web page by the DZ Dot browser add-on process 141 running in the browser, which examines the viewed web page against a site knowledge base. Information from the knowledge base is delivered to the browser processes dynamically via the DZ Dot server 15, from Dot Data storage 151, and updated when needed as determined by periodic checks. The knowledge base includes a list of URLs for each web page on which one or more DZDots will be placed to enable a user to select data adjacent to the dot, and a designation of the location on each page where the dot will be placed, along with a programmatic descriptors of the data, and, URLs by which data manifested on the page is actually accessed. The DZ Dot browser add-on process 141 considers any web page to determine if it is one from which the TS Resolver Server 16 can get data and should therefore receive placement of DZ-Dots in proximity to data which the TS Resolver Server can access. (This process also accesses instructions from a served file for the content for the menu, if any, to be served up to the user, upon hovering of the user's mouse over a DZDot and serves up that menu content.) The portion of the process that considers which web pages should be examined for DZDot candidacy gets its instructions from a file, entitled DZ-Algorithm, served by the DZDot server 15. The DZ-Algorithm is written in the ZithScript™ language described in the document attached hereto and incorporated herein as Appendix A hereto. Once a web page is determined by the aforementioned process to be a candidate for examination, each data object associated with a link (which is a URL) on that page is compared to any corresponding link syntax diagrams that appear in a “URL Includes” list and a “URL Excludes” list, to determine whether the data object associated with that link is specifically included to receive a DZDot or specifically excluded from receiving a DZDot. The DZ-Algorithms file may also contain instructions to delay running the process of applying all or portions of the knowledge base and other processes in order, for example, to allow the subject web page time to fully load. The DZ-Algorithms file may also include graphic rendering instructions for each DZDot so as to make it graphically compatible with the display conventions applicable to the location on the web page into which the DZDot is inserted. The DZ-Algorithm can be made operational not just on web pages which are themselves supported sources, but also on URLs, to those supported pages, that might be manifested on other web sites linking to those supported pages if the operators of the DZ system so desire or, in another embodiment of this invention, if the user so desires by choosing this option. This dot placement is described in further detail in connection with FIG. 9 below.

FIG. 4, we show placement of the DZDot on the home page of the Bureau of Labor Statistics at BLS.gov. In FIG. 5, we show placement of the DZDot on the Interactive Pages of the Bureau of Economic Analysis, which has a home page at BEA.gov. In FIG. 6, we show DZDots on the Financial Statement Pages, for GE Corporation, of WSJ.com. As can be seen from FIGS. 4 and 6, it is within the scope of embodiments of the present invention to place a plurality of dots on single web page, with each dot identifying a distinct cluster of data.

The placement of a DZDot on a web page can be achieved with surgical precision. To illustrate this feature, in FIG. 7, we show placement of a DZDot in a web page of the Bank of England, wherein the DZDot is placed immediately adjacent to alternate output format options, such as CSV, HTML and XML, that are present natively on the Bank of England web site. Positioning of the DZDot as shown enables the user to easily access the data extraction features of embodiments herein in a manner that is graphically and notionally compatible with output options provided natively on the Bank of England web site.

As shown in FIGS. 4-7, each DZDot appears adjacent to individual data or data collections that can be extracted and monitored by the DZ applications, including DataZephyr (the client side application previously described) and DataZoa (the web-hosted account described previously), as well as any other applications which are made to be DZ-data aware. (As previously discussed, the data may be numeric time series data, but may optionally be non-numeric series—e.g., a series of events—or simply numeric data that is not time-stamped or date-stamped).

Although the DZDots in FIGS. 4-7 have been described in the context of placement by processes running in the browser of the user of client computer 14 working in conjunction with the DZDot server 15, it is within the scope of embodiments of the present invention for the web site owner to cause placement of DZDots directly on the web site. Such placement may be achieved by snippets of code written for the purpose of placing such dots. The site owner causing placement of DZDots directly on the owner's site would thus make DZ compliant data on the owner's site readily and immediately accessible to the public in a normalized format via the user interface described herein.

-   -   FIG. 8 illustrates an embodiment of the user interface for         triggering the extraction of selected data in accordance with an         embodiment of the present invention. In order to cause         extraction of data from a web page manifesting the DZDot, the         user simply hovers the mouse (or finger, if using a touch         screen) over the DZDot (or clicks on it) that appears adjacent         to the data of interest. This user action causes the user to be         presented with a menu of choices, shown in FIG. 8, which         include, among other things: Drag this data to DataZoa     -   Drag this data to my DataZephyr application     -   Send this data to my DataZoa Account     -   Send this data to [the next free data window/s in] DataZephyr     -   Take (Drag or send) all DZDot flagged data on this web page into         my DataZoa Account     -   Take (Drag or send) all DZDot flagged data on this web page into         DataZephyr         In FIG. 8, when a user hovers over the DZDot, a visual         indicator, in this case, a right-downward-hooking arrow, is         displayed in the selected Dot to identify to the user the         specific data series or collection that will be acted upon         following the menu selection made by the user.

FIG. 9 is a block diagram showing processes carried out by the DZ Dot browser add-on 141 in placing a DataZither Dot at the time of loading of a web page having numeric data. In process 91, the DZDot browser add-on retrieves the URL of the web page open in the browser. In process 92, the DZDot browser add-on determines whether the process KeyDomains (which lists URLs that have been analyzed for placement of DataZither Dots) has been turned on, and if so, whether the URL is listed in KeyDomains. If the answer to either questions is “no”, then the DZDot browser add-on terminates dot placement processing in process 921. If the answer to both questions is “yes”, then in process 93, the DZDot browser add-on determines whether there are any remaining links on the web page to analyze. As long as there is a remaining link to analyze, the DZDot browser add-on performs link analysis by in process 94 determining whether the link is listed in the Includes list and in process 95 determining whether the link not listed on the Excludes list; unless both conditions are satisfied, the DZDot browser add-on moves on to consider the next link. If both conditions are satisfied, then, in process 96, the DZDot browser add-on places a DataZither Dot in the displayed web page adjacent to the object in the web page associated with the link. When in process 93 it is determined that there are no more links to process, the DZDot browser add-on moves in process 97 to determine whether there are any Zithscript algorithms specific to this URL in the DZ Algorithms list. If not, then in process 971, the DZDot browser add-on ends dot processing. If there are any Zithscript algorithms specific to this URL, then in process 98, the DZDot browser add-on runs the Zithscript algorithms, placing dots where specified by the algorithms, and if any algorithm so specifies, pausing the instructed number of milliseconds before placing the dot, in order to provide time for the web page to load. After running the Zithscript algorithms, in process 981, the DZDot browser add-on ends processing.

FIG. 10 is a block diagram showing processes carried out by an application (such as DataZephyr 143 running directly on client computer 14 or the DataZoa server 17 in conjunction with the DataZoa web page running in browser 142 of client computer 14) in relation to the TS Resolver Server 16 in accessing normalized data from a third party web site. In process 101, the relevant application receives a user command to acquire the numeric data from the third party web site. On such user command, for example, may be implemented by the user's use of a mouse to drag a DataZither Dot associated with the data of interest to the user into a target in the DataZephyr application or the DataZoa web page. In process 102, in response to this command, the application passes the URL of the web site, along with any other applicable data (which may be locational and/or be a query structure associated with the data of interest) the TS Resolver Server 16, and in particular to WDBDistributor module of the server. In process 103, the TS Resolver Server 16 receives the URL and other applicable data, and in process 104, the TS Resolver Server 16 determines if for the URL there is a script in site script storage 161. If there is no script, then in process 107 the TS Resolver Server 16 returns to the application an error message STATUSQUO and ends processing. If there is a script, however, then, in process 105, the TS Resolver Server 16 runs the script to acquire the data from the web site and to normalize the data. In process 106, the TS Resolver Server 16 sends the normalized data to the application, or, if an error resulted in acquiring and normalizing the data, an appropriate error message; and then the TS Resolver Server 16 ends processing.

FIG. 14 illustrates an aspect of the user interface of an embodiment of the present invention by which time series data appearing in a table of a web page, which table is being produced and served by a DataZoa account containing the underlying data, being viewed in the browser of client computer 14 may be imported into the DataZephyr charting and analysis application 143. In this example a calculation is performed on the time series data using DataZephyr. Specifically, the interface is designed so that the user may use the mouse to drag the name of a row or table or table series of interest (such as the row name “Arrivals”) from the displayed web page into the DataZephyr, where the row or table or table series is immediately charted (here, producing the chart W1 in DataZephyr). Similarly the user may drag the name “Expenditures in the Country” from the table of the displayed web page into DataZephyr to produce the chart W2. DataZephyr has been here invoked to calculate W3:=W2/W1, and the results of this calculation is another time series plotted as W3 in DataZephyr. DataZephyr is configured to cause updating of its charts (using the TS Resolver Server 16.

FIG. 15 illustrates an aspect of the user interface of an embodiment of the present invention by which time series data appearing in a table of a web page being viewed in the browser of client computer 14 may be imported into the user's DataZoa account via the DataZoa web page 142 of FIG. 1 in the browser of client computer 14. In this example, as shown in FIG. 15, the user has dragged the row name “Arrivals” from a table 153 in the displayed web page to the target 151 of the DataZoa web page 152. The DataZoa web page displays names of time series data in the user's DataZoa account, and here the top row 153 in the listing is identified as “Arrivals” as a result of the user's dragging the row name “Arrivals” from the table 153 to the target 151.

It is within the scope of embodiments of the present invention to provide other compliant applications that may similarly receive and cause updating of time series data that has been dragged from a table in a displayed web page. It is also within the scope of embodiments of the present invention for DataZoa to provide other types of displays which can serve to the user individual time series which the user may take into their DataZoa account or other compliant applications.

As discussed in connection with FIG. 11, time series data may be imported into DataZoa and other compliant applications using menu selection or other techniques as an alternative to dragging with the mouse. The functionality illustrated in FIGS. 11, 14, and 15 facilitates convenient acquisition, monitoring, updating, and use of time series data, and is an important source of value of embodiments of the present invention.

Branded Data.

In accordance with an embodiment of the present invention, the user's destination application will also manifest, if available, any web-based data source's favicon, which can be located on the source web site, and will place this icon, for example, in the lower right corner of a chart or listing of the data in the destination application (e.g., in the DataZephyr application or in the user's DataZoa account). While the favicon can be considered an alternative to a trademark or URL, in fact for purposes herein the favicon may usefully be implemented as a trademark that includes a hyperlink to the URL by which the relevant time series data may be accessed via the source. FIG. 17 provides detail of a portion of FIG. 12, showing, among other things, in each row, the web URL of the corresponding data in the DataZoa account as well as the favicon for such data. The favicon can also be displayed in other manifestations of the data, such as a table or chart produced by and/or served out to others, for example on the web, by the DataZoa account. The favicon will, by default, manifest that URL and other contextual data from the original site where the data came from, and will further enable the user to click on that icon and be delivered from the user's destination application (e.g., DataZoa account, DataZoa-served table or chart, or DataZephyr), to a fresh or open browser window or tab which will contain the URL for the original information, thus giving the user a convenient pathway back to the points of origin of their data.

This user clickable favicon or other trademark, which links back to the web page source of data (or to a special destination page for marketing purposes) provides a benefit to the data publisher in that it provides both branding for the publisher as well as a click-back link, adjacent to the publisher's data, even after the data has left the publisher's web site.

Data Served by the Publishing Features of DataZoa.

Even when the DZDot is not available on a web site, a DataZoa account can be used to publish and share numeric data, including publication of dynamic updates of this data. Thus a data owner or publisher for which a connector has not yet been established can use the publishing features of DataZoa to publish their data via DataZoa tables, charts and other display tools, which in turn empowers their site visitors to access and use the publisher's data in visitors' own DZ-Enabled applications, such as their DataZoa end-user accounts and DataZephyr desktop software applications.

More specifically, the data on an owner's site may also be data which is delivered to the site by tables, charts or other displays created and served up by the publisher's own DataZoa account, because one of the central features of DataZoa is that it can also be used as a data publishing platform. Note that such table, chart and other displays, including widgets, serve data which is implicitly able to be utilized with the DZ-dot access conventions set forth below, unless these capabilities are otherwise shut off by the data owner/publisher putting out such data display widgets. In lieu of the DZ-Dot, other indications of the ability of the data in such displays to be accessed by the DZ system may be relied upon, such as a distinctive highlighting or coloring of data, explicit statement that the numerical data can be captured using DataZoa, or the appearance of a branding or other marking, a name or URL including the letters DZ, some elements of the look and feel of the DZ-Dot, a right-mouse-button menu choice, or simply instructions or a link to instructions as to how to capture the data with the DZ system. For mobile devices, other user-interface conventions may be offered to enable a user to, for example, send data from such a display to their own DataZoa account or otherwise register it in their DataZoa account for monitoring. Thus while LMT creates connectors to various numeric-content hosting web sites, it also offers data owners the ability to become “DZ-compatible” by using the DataZoa data publishing tools.

FIG. 11 provides an example of a user interface for an embodiment of these DZ-compatible features. In this example, suitable controls appear below at the bottom or in other proximity to an embeddable table or chart or other display of data served by DataZoa. Specifically, “Get Data” and “Monitor” selectors in FIG. 11 are placed above a data table or chart or other data display to which the selectors relate, and enable the user to trigger actions, in relation to the data, that include, among other things, “Send to my DataZoa” or “Track in DataZephyr”.

FIG. 12 shows how publisher icons and clickable links can appear in a data listing view of an end user's DataZoa account. Here individual data series can be “hung out” on the web with publisher-determined click-back links which serve the publisher's marketing goals. DataZoa publishers have the ability to over-ride their click-back URL from favicon for marketing purposes. A publisher option exists for data published via DataZoa such that and end-user's click-back from such a favicon or other URL presented in association with such numeric data, could also go to a pre-specified web page, just like a paid ad on Google might manifest a “display url”, but would click back to an advertiser-specified click-back URL which could be different from the display URL. Thus, if the large global real estate CB Richard Ellis decided to publish data about city-level rents, vacancy rates, etc., from a DataZoa publisher account, series relating to the Hong Kong market, when their associated favicons or display URLs were clicked upon, would direct the user to, for example, the web page of the Hong Kong office of CB Richard Ellis.

Automatic Data Update Cycle.

DataZoa and DataZephyr can invoke the TS Resolver to check for updates from the original web-based data source or a DataZoa account. In the case of data from a DataZoa account, the user's application may receive a signal or data updates, which in the case of the former, notifies the application that new data is available. When the DZ compatible application gets its signal to check for updates, the same TS Resolver system is again activated, utilizing the “package” of information originally used to fetch and interpret from the web site or DataZoa-served table, chart or other display, and proceeds, in the manner described in connection with FIG. 2, to extract, normalize, and store the updated data in an array, which is then used to replace, including any new values, the data already known to the DZ-compatible application. Different choices for replacing versus simply augmenting the existing data in the DZ-compatible application may be exercised by the TSResolver system based on knowledge about the source of the data. In the context of a data update cycle, specific data values of a collection, for example, the June, 2012 unemployment rate, may be superseded by the data source with a revised June, 2012 value for unemployment. Alternatively, the data source might drop off and cease, either temporarily or permanently, providing one or more of the older or oldest values it previously maintained for the unemployment rate; for example, the July, 1952 rate might be dropped as the July, 2012 rate is added, in order to save storage space or web page space or for other reasons. To handle such circumstances, optionally the DZ system (i) archives the data collection as it existed prior to any revisions of such values as the June, 2012 value in the above example, and (ii) retains the oldest values in the same data collection in the user's DataZoa account. Thus, in this example, the user's account will have an archived time series for unemployment as it looked prior to the above-described revision of the then already published June, 2012 value. Additionally, the user's DataZoa account will retain older values, such as the July, 1952 et seq. unemployment rates as these were dropped from the data presented by the source.

Sharing Numeric Data from DataZoa Accounts to Other DataZoa Account Holders or Systems Working Through a DataZoa Account and its API.

Each DataZoa account can be used to share data via an email address identifier with another person who has, or is notified that they can open (via the email sharing message) a DataZoa account. As shown in FIG. 11, any number of series can be check-boxed and shared to individuals by specifying their email address and setting their access privileges. Once data is shared by one DataZoa account with one or more others, that numeric data is accessible for those permissions allowed to each such user, such as reading, sharing to others and/or editing of the data. For efficiency, once data is shared in this way, additional copies are not made of the data, but rather access permissions are simply attached to the accounts of those to whom data was shared, as well as being attached to the information in the primary holder's account. Similarly, in various embodiments a DataZoa account holder may render a table or other data display from which data can be effectively accessed or “borrowed” by a user and followed in the user's own DZ compatible applications, such as the user's DataZoa end-user account or DataZephyr. In such cases, the publisher of that data is permitted to see the number of individuals, and/or the identities of the individuals (as identified by their DataZoa account, typically registered with an email address) with whom the publisher had shared data or whom had “borrowed” the data from the publisher. A publisher having such data-item specific user/borrower information can use the information in a variety of commercial contexts, and of course end-users can be offered free data in exchange for allowing themselves to be identified and/or contacted by a publisher. Similarly, the ability to track data users/browsers can be used prior to granting access as a means of determining whether the user is permitted to access what may be paid subscription data. Finally, such DataZoa displays, which may, for example, take the form of tables showing only the names of various data items and/or the name and a short stub of the data, could serve as a data subscription marketing and selling platform to the underlying data and streams of data, not unlike a web site which sells music might enable the user to listen to a portion of a track of music, then purchase the entire track.

FIG. 18 illustrates a classic DataZoa-served table, which, in various embodiments of the present invention, can be inserted into any web site by using the link served up by the DataZoa table builder, which in turn is depicted in FIG. 19. Any DataZoa table can carry (i) data from any external source supported by the DZ-Dot processes described above via drag and drop or menu selection of sending the data to a user's DataZoa account, (ii) data from any other DataZoa table, from which data may be dragged and dropped into the account of the user rendering his own DataZoa table, (iii) data uploaded into a DataZoa account by a user, or (iv) data written into a DataZoa account by a computer process via the DataZoa API. DataZoa tables also offer the publisher the ability to turn on capabilities for the user such as (1) picking up an embed link to enable the exact depicted table to be embedded by the user on another web site, (2) downloading all the data behind the table, including historical portions of the series in the table which are not depicted in the current view, (3) sharing of the table via social networking services such as Facebook, Twitter and popular email services, and (4) downloading the DataZephyr viewer (also called DataZoa viewer) so that individual series in the table may be dragged and dropped by the user into DataZephyr for further viewing, live monitoring of updates from the DataZoa account behind the table, analysis, saving in DataZephyr worksheets, and emailing of DataZephyr worksheets to others.

FIG. 19 illustrates the table-building tool of DataZoa which was used to render the finished, web-delivered table in FIG. 18. This tool allows the user to specify in a form a set of criteria governing operation of the web-delivered table. The user may select via check-boxes, the series desired to be placed in the table, and then choose various options and controls such as number of time periods, and whether the table should always go to the “Latest” date, which means that it would roll forward in time as new data became available in the user's DataZoa account. (Such a mechanism removes data from the oldest time period to make room for data from the newest time period.) The DataZoa table building tool includes a label knockouts tool. This tool will pass through rows names in a table, which rows initially receive the sometimes rather long name for the series as it is delivered from the web site where it was found by the user, and suggest candidate text portions of those row names to “knock out” of the row labels, thereby reducing repetitive text from the row names. This is achieved by a computer process which examines all the row names for occasions of text which is repeated frequently and offering a “best guess” to the user for what should be “knocked out”, and presenting a table view with that best guess knocked out of the table.

Since DataZoa has an API for both reading data from DataZoa and writing data to DataZoa (at the account level), external systems may also effectively be the recipients of sharing transactions from DataZoa as data is shared to DataZoa accounts being used by such systems.

Data, Allowing Aggregation by Multiple Attribute Dimensions of the Raw Transaction Data, and Delivery of Data into Enabled Applications.

If the data source of interest to the user comprises a collection of transactions, such as from a user's bank debit card, each transaction typified by a date/time, but also such other attributes as a Store Name, City/Location, the DZDot may invoke a separate loop TS Resolver program/s to:

-   -   (1) extract the block of transaction data,     -   (2) offer up to the user menus of data attributes such as         “Vendor” and “Location”,     -   (3) invite the user to select some or all of the desired         dimensions along which to summarize the data (eg. by Vendor),         including the ability to include/exclude specific alternatives         among the class of Vendors found,     -   (4) allow the user to choose a data frequency for aggregation         (eg., weekly, monthly, daily, quarterly annually or no         aggregation), and then     -   (5) deliver an array of data conforming to the user's         summarization and dimensionality requests to the DZ-compatible         application.         The above case is typically one where the data originates in raw         transaction format, and the User is given the opportunity to         place their own interpretive rules upon the raw transaction         data, which rules become part of the subsequent Automatic Data         Update Cycle as described above and applied to that web page or         site where the user's transaction data of interest was found.

DataZoa manifests a novel “hunting scope” drop zone for dragged-in data, which then reports on data uploading progress to the user. In DataZephyr, the data flows directly into chart windows contained within DataZephyr. [add figures to describe these features]

Epochal Time Series.

Another aspect of embodiments of the current invention involves the ability to store an “epochal time series”, as defined above, wherein each value in the series is a function of a condition that changes with time, but not necessarily on a regular basis. As an example, the condition may be the identity of the Chairman of the Federal Reserve. Another example is where the function is of the identity of a baseball team's coach. Yet another example is where the function is of when a given team holds the World Series championship pennant. A further example is a function of each then active hurricane in a region. Such data are characterized by DataZoa as Epochal Time Series, and upon such Epochs being entered into DataZoa, can be depicted visually in charts such as in FIG. 16. Epochal time series are an important class of information which may give valuable interpretation of numeric time series data.

Up-Reporting/Sharing and Publication Release Control System.

A further embodiment of the present invention provides data publication and release authority controls. The data sharing capabilities of embodiments herein lend themselves to the needs of many primary data publishers, such as a country level statistical agency. Such agencies typically receive information from subsidiary agencies and ministries, for example the minister of tourism, who reports total tourist arrivals, and the minister of health, who reports births, deaths and myriad aggregate health statistics. Such staff members at such ministries may collect their statistics, enter them into a DataZoa account, and share them from their DataZoa account to their minister's account, who may in turn share his final figures with the country-level statistical office. This set of nested sharing arrangements provides an instantaneous pass-through and up-reporting of important statistical information. Because some level of review and approval may be desired as data moves from ground level up to the reporting hierarchy, and ultimately gets released to the public, further embodiments of the present invention include a pre-sharing-pass-thru-approval system, a pre-publication approval system, and a scheduled publication system, all as described below.

Pre-Sharing-Pass-Thru-Approval System.

This system provides the ability to establish, for any data series or collection of series, and any list of individuals to whom that data is shared within the DZ system, a list of (Internal Review) Approval Panels. For each Approval Panel there may be specified (a) one or more individuals identified by email address, (b) the number of members of the panel who must approve the data, (c) the number of vetos or negative votes required by members of the panel to stop an approval, (d) the identities of any Approval Panels which must pass on the data prior to the current Approval Panel being asked to examine the data, (e) any known date/s by which items in the data collection are needed to be approved or corrected prior to release.

Pre-Publication Approval System.

This system provides the ability to establish, for any data series or collection of series, or any data display widget, a list of (Publication) Approval Panels. For each such Panel, a similar set of specifications may be established.

Scheduled Publication System.

This system provides the ability to establish, for any data series or collection of series, or any data display widget, and for any specified data range (specified by date, time or other means), a set of specific dates and times for release of that data to the public via the specified widgets or other systems of data display, including public access via sharing to public or other access to public-facing display of DataZoa hosted data.

Upon the crossing of a sharing approval threshold in (i) or (ii) above, or a publication threshold in (iii) above, the prior existing data values may be optionally archived to enable backwards refreshing and other uses of this data.

FIGS. 20 and 21 are representations of displays of web pages in which appear DataZoa-served displays in accordance with an embodiment of the present invention providing the user with a series of options for using the time series data in the display, including the “follow” option by which the user may subscribe to time series data in the display. The “follow” option can be selected graphically in the display in FIG. 20 by clicking on the “dZ” graphic 201 associated with the “follow” option. Clicking on this graphic cause there to appear below the graphic, indicated generally by arrow 202, two separate links. One link is called “Follow this display” and the other link is called “all of these series”. Each link has a different functionality. The first link causes the entire display to appear in the user's account, if the display is not already owned by the user. The second link causes all of the time series data associated with the display to appear in the user's account, if the time series data is not already owned by the user. We show in connection with FIG. 25 below another method to invoke this functionality by a menu available in hovering over a row of a DataZoa-served display. FIG. 21 is a display of latest values, and a time series underlies this display. (For this reason, we still consider this display in this description and in the accompanying claims to be of time series data. In this context, still by clicking on the “dZ” graphic 211 associated with the “follow” option, the user is similarly present with the same kinds of links as in the case of FIG. 20 and presenting the same “follow” options.

FIG. 22 similarly illustrates a web page in which appears a DataZoa-served bar chart in accordance with the same embodiment as FIGS. 20 and 21, wherein the user provided with a series of options for using the time series data in the bar chart, including the “follow” option. The “follow” option can be selected graphically in the table in FIG. 22 by clicking on the “dZ” graphic 221 associated with the “follow” option.

The “follow” functionality enables a casual observer of a web page in which appears a dataZoa-served table or chart to (i) open a dataZoa account, (ii) post the content constituting the table or chart or a part of it into their dataZoa account (in fact, as we describe in connection with FIG. 23, to a dZBoard named “Latest Arrivals”) and (iii) follow all the time series behind the this content in their dataZoa account. The “follow” option thus enables one to subscribe to dynamically updating data displays and dynamically updating time series which one finds on the web or which has been shared with one. The “follow” option in this embodiment therefore provides for time series data what Twitter does for “Tweets”. A Publisher can post dynamically updating data displays based on underlying time series data, and other can follow these displays and the underlying time series data on their “Latest Arrivals” screen, as well as following the underlying streams of numbers in their own DataZoa account.

FIG. 23 is a representation of a display of a web page of a DataZoa user account using the “Latest Arrivals” screen (which is a default “dZBoard”) of the dZBoards feature associated with a DataZoa user account in accordance with an embodiment of the present invention and showing the appearance in the account of the tables of FIGS. 22 and 20 after election of the “follow” option for such tables.

FIG. 24 is a representation of a display of a web page of a DataZoa user account showing another screen (which is a user-customizable “dZBoard”), of the dZBoards feature associated with a DataZoa user account in accordance with an embodiment of the present invention, wherein one can compose a web page including text and one or more tables or charts or both that are served by DataZoa, and cause the web page to be shared privately or publically for viewing on any web-enabled device.

From our discussion it can be seen that dZBoards are a means of organizing, presenting and sharing DataZoa “embeddable” time series data (such as tables and charts of such data) also known as dZEmbeddables. A dZBoard comprises one or more dZEmbeddables organized in a list that can be edited, arranged and annotated (including the addition of text or other HTML manifestation which can be placed above, below and adjacent to any dZEmbeddable), and then displayed through a single URL. The representative URL can be shared and viewed through commonplace means such as email, blog posts, and custom web pages. The resulting dZBoard can be viewed on a personal device such as an iPhone, Android device, iPad, PC or any device which is web enabled. Among the major benefits of dZBoards is that the dataZoa account-holder can effectively render individual, stand-alone web pages for personal use or the use of others. Such pages can also link to each other, resulting in an effective “DataZoa blog” or “DataZoa site”. This is of particular value to DataZoa account holders who do not otherwise have their own web sites but who wish to publish web pages leveraged by data in their DataZoa accounts. Another important benefit is the ability to use the dZBoard facility as a report writer to generate reports for individual, group or public use that are updated automatically, and can be manifest on personal web-enabled devices of the relevant audience. Thus unlike early mainframe computer report writers, which delivered a custom, static, hardcopy report, dZBoards deliver a dynamic, always current report manifesting the latest data available flowing through DataZoa's dynamically updating embeddables directly to the dZBoard. As an example, an executive can be in a meeting, or in transit, and in single finger-touch on his web-enabled mobile phone, access an up-to-the-minute dZBoard, reflecting the latest values available in the underlying DataZoa account that drives the display.

A dZBoard is owned by a DataZoa User Account and can be made public, private, or be made selectively available via a password specific to a particular dZBoard. The dZEmbeddables so comprised may be owned by the User Account or may be accessed from other User Accounts if they are publicly available.

FIG. 25 is a representation of a display of a web page in which appears a DataZoa-served display in accordance with an embodiment of the present invention wherein a user is provided with options, labeled with the Grey dZDot, for use of the display or its underlying data, including two distinct “follow” options (here indicated as “send” options) by which the user may subscribe to time series data in the row or in the entire display and have the subscribed data appear in the user's DataZoa account, if the user is not already the owner of the data and the owner has not disabled the “follow” option. The web page is configured so that when the user's mouse is caused to hover over selected portions of the web page, such as a row, the Grey dZDot appears and then, after a moment, a menu appears in a pop-up window with various possible options for use of the time series data in the table, Besides the options to subscribe to time series data in the row or in the entire display, other options include dragging the series into the DataZephyr application for graphing or manipulation purposes; getting a free DataZoa account; and getting a free DataZephyr application.

FIG. 26 is a representation of a display of a web page in which appears a DataZoa-served table in accordance with an embodiment of the present invention, wherein an option is presented to have data in the tabled mirrored in a spreadsheet and repetitively updated in the spreadsheet.

FIG. 27 is a representation of display of an Excel spreadsheet in which there has been installed a DataZoa add-in, which has been invoked so as to trigger a pop-up window by which one can enter a URL to identify a table (such as the table of FIG. 26) that is to be mirrored in the spreadsheet and to specify the update frequency by which the data in the spreadsheet will be updated, all in accordance with an embodiment of the present invention;

FIG. 28 is a representation of display of an Excel spreadsheet in which there have been mirrored a number of DataZoa-served tables, using the DataZoa add-in of FIG. 27, in accordance with an embodiment of the present invention. We discuss processes involved in mirroring in connection with FIG. 36. As we have discussed, the Mirror button enables a user to have a live DataZoa table mirrored in their Excel spreadsheet software, including setting of the data update interval to keep abreast of new values. Thus a user is enabled to have his own Excel formulas and other data fed by the dynamically updating table provided by the DataZoa server. The user merely invokes the mirror button in the DataZoa-served table of interest and follows the simple instructions to have a desired DataZoa table mirrored in his Excel spreadsheet.

FIG. 29 is a representation of a display of a web page of a DataZoa user account using the DZ Slates feature by which the user can create and e-mail a web page, repetitively if desired, to a data contributor of the user, for use by the contributor in causing a direct upload, to the user's designated URL, of the contributor's data in accordance with an embodiment of the present invention.

FIG. 30 is a representation of a display of a web page that results when the data contributor of FIG. 29, having received the e-mailed web page, activates the “slate” by which the data contributor can enter data, requested by the user, directly to the user's designated URL, in accordance with an embodiment of the invention providing the DZ Slates feature.

FIG. 31 is a representation of a display of a web page by which the user can configure and edit the context in which the data contributor can enter data, including target URL for data upload, contributor e-mail address, optionally required password, and greeting to the contributor, in accordance with an embodiment of the invention providing the DZ Slates feature.

An important benefit of dZSlates is effectively “Teeing up the data contribution ball” by presenting, to the those who have needed data, a perfectly scoped data entry form that presents a rolling history of recent prior values for the data items needed, as well as presenting the “gap” for the most recently requested data with simple data entry cells for those values. Values can be entered manually or copied and pasted into the form. By structuring the data contribution transaction in this fashion, the timeliness and accuracy of the data are facilitated.

The dZSlates functionality assists in consistently updating data series over time and allows collaborative contributions from others selectively, without granting full account access. In implementation, dZSlates are hosted in a User Account at a DataZoa server. They are accessed through a URL that allows access to specific prescribed data series in that account. The access is protected by a password specific to that dZSlate. The dZSlate-specific URL is made available to outside contributors via email notification. In a further enhancement, email notification can be offered to contributors periodically, on a schedule tied to the periodicity of the data series prescribed in the dZSlate, and reminders of not-yet-supplied data can be sent via email notification, at a chosen reminder frequency until such time as the period-appropriate data are contributed. In a further enhancement, contributed data values can be marked as provisional, and blocked from flowing through to DataZoa public data displays, until approved by the owner of the DataZoa User Account. In a further enhancement, contributed data values can be marked as requiring the signoff/approval of one or more members of one or more data-approval groups before the data-contribution transaction is submitted by the data contributing process into the view of the owner of the DataZoa account. The signoff/approval of members of a data-approval group/s is a process which can be administered via email notifications to the members of the data-approval group/s, some pre-defined threshold number/s of whom must sign off on the data prior to submission into view of the DataZoa account owner. The data approval groups can be set in a sequence or hierarchy such that lower level approvals must occur first before higher level approvals are requested, with each level of the hierarchy being able to see the trail of approvals which have already occurred, including identity of approvers and date/time stamp of their approvals. Notification of a needed approval and reminders of not-yet-approved data updates needing approval group members' approvals are sent via email.

The constellation of features associated with embodiments of dZSlates (including customizable message content, customizable data entry fields, automated distribution and reminders) make it an excellent vehicle for conducting surveys without any change in the underlying structure of dZSlates.

FIG. 32 is a representation of a display of a web page proving to the user guidance on configuring and using DZ Slates for gathering data.

FIG. 33 is a block diagram of system architecture of an embodiment of the present invention for implementing the DataZoa server 17 of FIG. 1 as a series of peer-to-peer servers for handling loads larger than could be handled by a single server. A “sharded” architecture dividing a single logical appearance over several distinct machines is used to fulfill requirements that cannot be met in a single physical machine. User requests arrive from the Internet and are handled by one of several Peer machines 331. A user request may require data from several User Accounts in order to be fulfilled, but the description of how to fulfill the request is always a property of some single User Account. Thus a single particular Peer machine is responsible for assembly and return of a response, but that Peer may coordinate with and rely upon other Peers to do so.

There are potentially millions of User Accounts, each containing potentially millions of data series. This scale is beyond the practical physical capabilities of individual machines. The distributed nature of request fulfillment requires a data store that is logically integrated as a single unit but is physically partitioned (“sharded”) into several separate data stores in order to achieve the scale requirements. Each Peer machine is the repository for data in one or more User Accounts. All data for a particular User Account is stored on a particular Peer machine.

Because user requests may require information from several different User Accounts from several different physical storage shards, it is important that all User Account information and coordinating information remain highly available. Each Peer machine has an associated Warm Backup machine, in the set of Warm Backup machines 332, which keeps a complete copy of the Peer machine's data store and is available to answer queries on behalf of the Peer machine in the event it is unavailable because of failure or maintenance activity. Together these two machines are a “Peer Cluster.”

All Peer Machines rely on a centralized dZDNS machine 333 to resolve questions about which Peer Cluster and specific machine (Peer machine or Warm Backup) is responsible for a particular User Account and its associated data. The dZDNS machine 333 has an associated Warm Backup dZDNS machine 334 which keeps a complete copy of the dZDNS machine's data store and is available to answer dZDNS queries in the event the dZDNS machine is unavailable because of failure or maintenance activity. Together these two machines are a “dZDNS Cluster.”

FIG. 34 is a block diagram of logical flow for the system architecture of FIG. 33. Storing data and routing requests among many distinct machines while maintaining the logical appearance of one seamless serving machine. As User requests arrive from the Internet, they contain information that associates the request with a particular User Account. That identifying information is used to route the request to appropriate resources for fulfillment. A request for User Account “X” is sent to a generic Load Balancer in process 341 which assigns the request to the next available Peer machine as a “broker”, without regard to any particulars in the request.

In process 342, the broker Peer machine uses the dZDNS service 343 to identify which particular Peer machine “N” is responsible for User Account X. The broker Peer machine may in fact turn out to be the appropriate Peer N. Also, in practice, if Peer N is unavailable, the dZDNS service may identify Warm Backup N rather than Peer N as the appropriate member of Cluster N to handle the request. For this discussion we will refer only to Peer N for the sake of simplicity. If the broker Peer machine is not identified as the appropriate Peer N to handle the request, the broker Peer forwards the request to Peer N as part of process 342. Otherwise, the request is handled by the broker Peer in its role as Peer N.

At Peer N, the request is processed in process 343. This may involve gathering and coordinating data from User Accounts other than X, and perhaps from other Peer machines 345. Peer N relies on dZDNS services 344 to locate and coordinate these additional resources. When the response to the request is assembled, it is returned to the broker Peer (if not already Peer N), which then returns it to the Internet requestor.

FIG. 35 is a block diagram of logical flow for processes by with the DataZoa server 17 of FIG. 1 causes time series data stored by it to be updated. After a DataZoa user obtains data from a particular URL, DataZoa keeps the data current in the user account by automatically revisiting that URL from time to time in order to see if the data at the URL has been updated. If the data at the URL is found to have changed, the data is processed and posted to DataZoa storage as appropriate. A particular URL may supply data to more than one DataZoa user and may update more than one DataZoa time series.

Even though the data at a URL may change infrequently (once a month, for example), it is necessary to fetch the URL often in order to reflect changes in a timely fashion. Data sources do not typically have precisely implemented calendars or other external signals to show that they have been updated. Thus frequent fetching is required, and the overwhelming majority of data fetches are a waste of time and resources for all parties.

We have developed the concept of “Release Groups” as a method of utilizing certain data site policies to minimize fruitless fetches and maximize timeliness. The publishers of some data sources may, as a matter of policy, release data updates as coordinated groups, rather than sporadic events. Such data sources and policies can be identified as a “Release Group” (RG) in DataZoa. Where possible, Release Groups are utilized to minimize the time and resources required to rule out superfluous data fetches at URLs that belong to the Release Groups. This is achieved by testing only a few URLs within the Release Groups, and then making a determination whether the Group as a whole has been updated and should be fetched in its entirety, or can be safely skipped based on the sample fetched.

As implemented in DataZoa, a Release Group comprises a distinctly recognizable set of required common substrings among URLs. These substrings may be organized as hierarchical layers, or “plies” where each Release Group is ultimately distinct but may share a common substring in a higher level ply. These plies are used to optimize the problem of testing each and every URL for membership in every known Release Group. Each Release Group also specifies a threshold of the number of URLs that must be tested and found invariant in order to conclude that the group represented as a whole has not changed.

For the foregoing processes, we present some logic pseudo code to provide more detail:

For each URL fetch candidate (process 351 of FIG. 35):

If URL is not part of a Release Group (determined in process 3521), fetch (process 352) and continue to next URL (process 351)

If part of a Release Group and the Release Group is known to have changed (determined in processes 3522 and 3523), fetch (process 353) and continue to the next URL (process 351).

If part of a Release Group and the Release Group is known not to have changed (determined in process 3541), continue to the next URL (process 351).

If part of a Release Group and the Release Group is not yet determined to have changed or not (process 3541), fetch (process 3542). If the fetch reveals a change (determined in process 3543), mark this release group as known to have changed (process 3544). If the fetched data has not changed, add one “vote” for marking as known not to have changed (in process 355). If enough votes have accumulated (determined in process 356), mark the Release Group as known not to have changed (in process 357).

A fragment of a typical Release Group file looks like this:

# URLs containing ALL of these strings will SAMPLE for evidence of change on a poll cycle

#

# Structure:

#

# TESTS NEEDED—number of fetches needed to conclude if this pattern is skippable

#|—field separator

# PLYn—one or more required matching fragments

#

# e.g. 3|SurveyOutputServlet|series_id=AP

# e.g. 5|doleta.gov

#

### BEGIN BLS Survey data

3|SurveyOutputServlet|series_id=AP

3|SurveyOutputServlet|series_id=BD

. . .

3|SurveyOutputServlet|series_id=WP

3|SurveyOutputServlet|series_id=WS

### END BLS Survey data

#

### DOL

2|doleta.gov/unemploy/wkclaims/report.asp

FIG. 36 is a block diagram of logical flow and user interaction by which a data in a DataZoa-served table can be mirrored in a spreadsheet. The representation of the contents is a copy of the numbers and labels in the HTML cells of the dZEmbeddable into spreadsheet cells in the Excel spreadsheet. Thus the term “mirror” in that the table contents is effectively mirrored in the user's spreadsheet. The contents thus “mirrored” is refreshed whenever the spreadsheet is re-opened and also periodically on a timed cycle as long as the spreadsheet remains open. In process 361, the user elects to mirror a DataZoa-served embeddable. In process 362, there is determination whether the user has installed an Excel plug-in for DataZoa, and if not, in process 363, the user installs the plug-in. After that, or otherwise, in process 364, the user invokes the Mirror functionality to obtain a URL link and uses the plug-in to invoke the link so that the spreadsheet is repetitively updated in process 365. The user is offered the ability to set the mirror updating frequency at some number of minutes, hours or days, at the time the DataZoa table mirroring is established. In a further embodiment the update frequency can be changed by the user at will from within Excel. In alternate embodiments, the mirroring of new time-period values from a DataZoa table can be reflected by adding successive columns for each new time-period to the user's spreadsheet copy in Excel (i.e., retaining all of the earliest time-period columns seen by the user and adding new ones for new time-periods as they are put forth in the dataZoa table), or by dropping off older columns as new columns are added in direct correspondence to the observable manifestation of the DataZoa table being mirrored. dZMirror is activated when a user, viewing a dZEmbeddable where the dZMirror feature is enabled, elects the mirror feature. The user has the option of downloading and installing the plug-in if they have not previously done so, and can set further options for the mirroring from within Excel once the mirroring is established. In process 366, the user stores the worksheet and exits Excel, and in process 367, can reopen the spreadsheet at a later time to cause renewed updating of the data in process 365.

Implementation of calculated series in DataZoa.

We address here a further embodiment of the present invention that enables the defining and evaluating of mathematical relationships using DataZoa-served time series data, and reevaluating the defined express whenever the underlying time series data are altered. To implement calculated series in DataZoa, we model every DataZoa series a potential vertex in one or more directed acyclic graphs (DAGs). The edges of a given DAG which connect vertices are defined by the mathematical relations between vertices. The evaluation order of the DAGs is established through topological sorting.

A benefit of this model is that a user's desired calculation of derived series values is performed continuously as new data which drive the calculation appear anywhere within the DataZoa ecosystem, so the calculated values are “always on” and available. This approach stands in sharp contrast to a typical prior art approach of having one's desired calculations buried within a stored spreadsheet that must be opened and activated manually and updated with new source data manually (or in some cases pulled via macros from a database). Little “user-sophistication” is needed to take advantage of the continuous calculation update aspects of dZCalculation. One simply uses the desired data to feed one's calculation, and as any of that feeding data changes in the DataZoa ecosystem, the user's calculation is updated automatically.

Calculated Series are owned by distinct DataZoa User Accounts, just like non-calculated series. Calculated Series may depend on other Calculated Series. Calculated Series in a given User Account may depend on series from another User Account. The interdependencies among Calculated Series can span separate Shards, but must preserve the logical appearance of a single unified set of calculation nodes. Whenever a non-calculated series anywhere in DataZoa is updated, any Calculated Series that depend upon the non-calculated series must be recalculated. Whenever the definition of a Calculated Series is changed, any other Calculated Series that depend upon the changed one must be recalculated,

For output purposes, Calculated Series participate in the same display mechanisms as non-calculated DataZoa series. For input, Calculated Series use interfaces designed for the definition of mathematical formulae rather than actual numeric values.

One input method uses web-based input forms where mathematical equations can be typed directly, using DataZoa series names as operands and standard mathematical notation for operators. Another web-based forms method of input involves dataZoa series first being identified by the user as being involved in a calculation, which are then each gathered in a list at the top of the calculation form, associated by the form with a short mnemonic, such as a succession of alphabetical characters (A, B, C, D, etc.) or a succession of numbered alpha characters (S1, S2, S3, S4, etc). The identification of the series s being involved in the calculation is achieved by the user checkboxing a group of series and/or successively checkboxing or dragging and dropping individual series into the calculation form, which then assigns the next successive short mnemonic to the most recent series added to the form.

Yet another input method uses interoperation with the DataZephyr to define Calculated Series. In this method, the User clicks and drags data elements from a dataZoa display into a DataZephyr worksheet, uses the DataZephyr formula conventions to define relationships, and then defines one or more resultant series as Calculated Series in a DataZoa User Account. This method has the benefit of enabling the user to visualize the stages of a calculation among multiple series, including breaking it into intermediate stages, as well as making it easy to make individual derived series out of both the intermediate and final stages of a calculation, simply by dragging and dropping the stage (intermediate or final) into DataZoa.

In a further embodiment, the output of a calculation is marked as “preliminary”, meaning that it is not considered “official” and fed to public- or private-facing displays until the account owner approves the calculated value for release. Such approvals may be achieved through approval groups or approval group hierarchies as described elsewhere.

In further embodiment, each series in the DataZoa ecosystem that is being used (depended upon) by a calculation anywhere else in the ecosystem can be called a “Parent Series” and, as a Parent Series, it knows (and can manifest) the date/time stamp of its own last change/s in any value/s in itself and/or the addition of new values to the series. Each Parent Series used (depended upon) by others in calculations has associated with it a list of the identities, DataZoa account holders and physical locations of those calculated series (Child Series) which depend upon it. Each derived series (call it a “Child Series”) in DataZoa knows the identity, account owner and server-series-location of each series in the DataZoa ecosystem upon which it depends (call these “Parent Series”). It also knows (and can manifest) the date/time stamp of its own most recent calculation update, AND the then-current date/time stamp of the latest update manifest in each Parent Series upon which it depended at the time the Child Series was last calculated. Thus at any point in time, it can be determined whether a given calculated Child Series is current by checking to make sure that the date/time stamps for each of its Parent Series when last used to calculate the Child Series values are the same as the latest date/time stamp then manifest by each parent.

Each DataZoa account having calculated series (Child Series) which depend upon other series (Parent Series) in the DataZoa ecosystem can have a Calculation-Supervisor Process (CSP) running which is responsible for watching out for changes in the Parent Series which any account's calculated series depend upon, and driving a calculation update of dependent (Child) series. The process of updating dependent (Child) series can be driven by the following method. Specifically, upon the event of a change in a Parent Series anywhere in the DataZoa ecosystem, notifications are composed and immediately sent to the CSPs that update calculations are needed, which notifications can be sent as topologically ordered instructions for calculations so as to assure that intermediate values are calculated in the correct order. Given that calculation interdependencies can span different shards, the ordered performance of calculations requires inter-shard manifestation and notification of calculation completion status so that each successive calculation can be performed in the proper order.

In an alternate embodiment, calculation update logic is consolidated in a large, centralized computer or network of computers which is aware of compute interdependencies and maintains an always-current topological order, and can thus supervise the ordering of calculations across the DataZoa ecosystem, either sending ordered instructions to CSPs for each account, or even performing the necessary calculations and sending updated series values and/or blocks of updated series values, or alternatively, maintaining a cache of latest values which is checked by individual accounts, including their embeddables, whenever series values are needed to be used, which accounts then refresh their values upon learning of new cached values.

The “Follow” Functionality Time Series and for dZEmbeddable Displays.

Not all time series data appearing on web pages from the DataZoa server originate from the account owner. Specifically, a given account holder may choose to create, using the DataZoa server, a display of time series data from one or more accounts other than that of the given account holder. For example, in a dZEmbeddable table display, each data row may correspond to a distinct time series, and those series may in all or part be owned by other accounts. Similarly, if the account holder so chooses, he can enable other account holders in turn to have account access to the time series in the display. Furthermore, if he so chooses, the account holder can enable others to have access to the display in its entirety. We refer to users accessing time series in other accounts without making privately owned copies as “following” those time series. Similarly, we refer to linking to a display in another user account as “following” a display. Importantly, because no copies are made, any “followed” items are by definition up to date. Any user accessing data via a “follow” is guaranteed to see the latest version of that data because ultimately only the original items are used in any rendering. Examples of such displays appear in FIGS. 20 (a time series table), 21 (a latest values display), 22 (a chart), and 25 (a latest values display). In FIGS. 37 and 38, we discuss logical flow in connection with using the “follow” functionality in to provide account access to time series data and the entire display respectively.

FIG. 37 is a block diagram of logical flow in connection with an embodiment of the present invention wherein the “follow” functionality (labeled as “Send” options in FIG. 25) has been invoked with respect to a time series. When the user invokes such a selection 371, a request is sent to the DataZoa Server 17 for processing. Process 372 determines whether the user has a user account. If not, the user is afforded the opportunity to create a new account in process 373 and upon completion process 378 creates a link (or links) to the requested data in the new account, completing the Follow transaction. If process 372 has determined that the user already has an account, process 374 determines whether any series in the request are owned by the user. If all are owned by the user, process 376 indicates that the user cannot follow data that the user owns, and then processing terminates. For any requested series not owned by the user, process 375 determines whether the user is already logged in. If not, process 377 affords the user the opportunity to log in. Once the user is or has become logged in, process 378 creates a link (or links) to the any requested data not already owned or followed in the user account, completing the Follow transaction.

FIG. 38 is a block diagram of logical flow in connection with an embodiment of the present invention wherein the “follow” functionality (labeled as “follow this display” 202 in FIG. 20) has been invoked with respect to a dZEmbeddable display of time series data. When the user makes such a selection to follow a display of time series data in process 381, a request is sent to the DataZoa Server 17 of FIG. 1 for processing. Process 382 determines whether the user has a user account. If not, the user is afforded the opportunity to create a new account in process 383 and, upon completion, process 388 creates a link to the requested display of time series data in the new account, completing the Follow display transaction. If process 382 has determined that the user already has an account, process 384 determines whether the display requested is owned by the user. If so, process 386 indicates that the user cannot follow a display that the user owns, and then processing terminates. If not, process 385 determines whether the user is already logged in. If not, process 387 affords the user the opportunity to log in. Once the user is or has become logged in, process 388 creates a link to the requested display of times series data in the new account, completing the Follow display transaction.

The embodiments of the invention described above are intended to be merely exemplary; numerous variations and modifications will be apparent to those skilled in the art. All such variations and modifications are intended to be within the scope of the present invention as defined in any appended claims. 

What is claimed is:
 1. A computer-implemented method of making updated time series data available to a client computer of a given user having a user account, the time series data having been graphically selected by the given user, the method comprising: serving by a time series server the time series data in a web page over a wide area network in such a manner that, when a user of a client computer displaying the time series web page graphically selects the time series data to be made available, there is provided to the server by the browser a unique identifier of an underlying location, of the time series, wherein the time series data is stored on the server; receiving at the server the unique identifier as a result of the graphical selection of the time series data by the given user; and modifying data associated with the given user's account so as to associate the unique identifier with the given user's account, so that when the given user, via a client computer, seeks to access the time series data having the unique identifier, then the time series data is retrieved from the underlying location, and so that whenever the time series data is updated at the underlying location the time series data accessible by the given user is also updated.
 2. A computer-implemented method of making an updated display of time series data available to a client computer of a given user having a user account, the display having been graphically selected by the given user, the method comprising: serving by a time series server the display in a web page over a wide area network in such a manner that, when a user of a client computer rendering the display of time series data graphically selects the display of time series data to be made available, there is provided to the server by the browser a unique identifier of an underlying location of the display of time series, wherein the display of time series data is stored on the server; receiving at the server the unique identifier as a result of the graphical selection of the display by the given user; and modifying data associated with the given user's account so as to associate the unique identifier with the given user's account, so that when the given user, via a client computer, seeks to access the display of time series data having the unique identifier, then the display of time series data is retrieved from the underlying location, and so that whenever the display is updated at the underlying location the display accessible by the given user is also updated. 